Meeting Pearls 1/Meeting Pearls Vol 1 (1994).iso/installed_progs/text/faqs/firewall-faq/text0000.txt

Text File | 1994-06-13 | 26.1 KB | 663 lines

Archive-name: firewalls-faq
Posting-Frequency: whenever updated
Last-modified: Mon Jun  6 10:17:59 1994
Version: 3

Internet Firewalls Frequently Asked Questions
=============================================

About the FAQ
=============
This FAQ is not an advertisement or endorsement for any
product, company, or consultant. The maintainer welcomes input
and comments on the contents of this FAQ. Comments related
to the FAQ should be addressed to [e-mail].


Contents:
=========
1: What is a network firewall?
2: Why would I want a firewall?
3: What can a firewall protect against?
4: What can't a firewall protect against?
5: What are good sources of print information on firewalls?
6: Where can I get more information on firewalls on the  network?
7: What are some commercial products or consultants who sell/service firewalls?
8: What are some of the basic design decisions in a firewall?
9: What are proxy servers and how do they work?
10: What are some cheap packet screening tools?
11: What are some reasonable filtering rules for my Cisco?
12: How do I make DNS work with a firewall?
13: How do I make FTP work through my firewall?
14: How do I make Telnet work through my firewall?
15: How do I make Finger and whois work through my firewall?
16: How do I make gopher, archie, and other services work through my firewall?
17: What are the issues about X-Window through a firewall?
18: Glossary of firewall related terms

------------------------------

Date: Thu Mar 3 12:35:59 1994
From: [e-mail]
Subject: 1: What is a network firewall?

A firewall is any one of several ways of protecting one
network from another untrusted network. The actual mechanism
whereby this is accomplished varies widely, but in
principle, the firewall can be thought of as a pair of
mechanisms: one which exists to block traffic, and the other
which exists to permit traffic. Some firewalls place a
greater emphasis on blocking traffic, while others emphasize
permitting traffic.

------------------------------

Date: Thu Mar 3 12:36:15 1994
From: [e-mail]
Subject: 2: Why would I want a firewall?

The Internet, like any other society, is plagued with the
kind of jerks who enjoy the electronic equivalent of writing
on other people's walls with spraypaint, tearing their
mailboxes off, or just sitting in the street blowing their
car horns. Some people try to get real work done over the
Internet, and others have sensitive or proprietary data they
must protect. A firewall's purpose is to keep the jerks out
of your network while still letting you get your job done.

Many traditional-style corporations and data centers have
computing security policies and practices that must be
adhered to. In a case where a company's policies dictate how
data must be protected, a firewall is very important, since
it is the embodiment of the corporate policy. Frequently,
the hardest part of hooking to the Internet, if you're a
large company, is not justifying the expense or effort, but
convincing management that it's safe to do so. A firewall
provides not only real security - it often plays an
important role as a security blanket for management.

Lastly, a firewall can act as your corporate "ambassador" to
the Internet. Many corporations use their firewall systems
as a place to store public information about corporate
products and services, files to download, bug-fixes, and so
forth. Several of these systems have become important parts
of the Internet service structure (e.g.: UUnet.uu.net,
gatekeeper.dec.com) and have reflected well on their
corporate sponsors.

------------------------------

Date: Thu Mar 3 13:24:13 1994
From: [e-mail]
Subject: 3: What can a firewall protect against?

Some firewalls permit only Email traffic through them,
thereby protecting the network against any attacks other
than attacks against the Email service. Other firewalls
provide less strict protections, and block services that are
known to be problems.

Generally, firewalls are configured to protect against
unauthenticated interactive logins from the "outside" world.
This, more than anything, helps prevent vandals from logging
into machines on your network. More elaborate firewalls
block traffic from the outside to the inside, but permit
users on the inside to communicate freely with the outside.
The firewall can protect you against any type of network
borne attack if you unplug it.

Firewalls are also important since they can provide a single
"choke point" where security and audit can be imposed.
Unlike in a situation where a computer system is being attacked
by someone dialing in with a modem, the firewall can act as
an effective "phone tap" and tracing tool.

------------------------------

Date: Thu Mar 3 14:02:07 1994
From: [e-mail]
Subject: 4: What can't a firewall protect against?

        Firewalls can't protect against attacks that don't
go through the firewall. Many corporations that connect to
the Internet are very concerned about proprietary data
leaking out of the company through that route. Unfortunately
for those concerned, a magnetic tape can just as effectively
be used to export data. Firewall policies must be realistic,
and reflect the level of security in the entire network. For
example, a site with top secret or classified data doesn't
need a firewall at all: they shouldn't be hooking up to the
internet in the first place, or the systems with the really
secret data should be isolated from the rest of the
corporate network.

            Firewalls can't protect very well against things
like viruses. There are too many ways of encoding binary
files for transfer over networks, and too many different
architectures and viruses to try to search for them all.
In other words, a firewall cannot replace security-
consciousness on the part of your users. In general, a firewall
cannot protect against a data-driven attack -- attacks in which
something is mailed or copied to an internal host where it is
then executed. This form of attack has occurred in the past
against various versions of Sendmail.

------------------------------

Date: Thu Mar 24 13:46:32 1994
From: [e-mail]
Subject: 5: What are good sources of print information on firewalls?

There are several books that touch on firewalls. The best
known are:

Cheswick and Bellovin, "Firewalls and Internet Security:
Repelling the Wily Hacker"  Addison-Wesley, ??, 1994

Garfinkel  and Spafford, "Practical UNIX Security"  O'Reilly
and associates (discusses primarily host security)

Related references are:

Comer and Stevens, "Internetworking with TCP/IP" Prentice Hall, 1991

Curry, "UNIX System Security" Addison Wesley, 1992

------------------------------

Date: Thu Mar 3 13:48:14 1994
From: [e-mail]
Subject: 6: Where can I get more information on firewalls on the network?

Ftp.greatcircle.com - Firewalls mailing list archives.
        Directory: pub/firewalls

Ftp.tis.com - Internet firewall toolkit and papers.
        Directory: pub/firewalls

Research.att.com - Papers on firewalls and breakins.
        Directory: dist/internet_security

Net.Tamu.edu - Texas AMU security tools.
        Directory: pub/security/TAMU

    The internet firewalls mailing list is a forum for firewall
administrators and implementors. To subscribe to Firewalls, send
"subscribe firewalls"
in the body of a message (not on the "Subject:" line) to
"[e-mail]". Archives of past Firewalls postings are
available for anonymous FTP from ftp.greatcircle.com in pub/firewalls/archive

------------------------------

Date: Thu Mar 3 12:38:10 1994
From: [e-mail]
Subject: 7: What are some commercial products or consultants who sell/service firewalls?

We feel this topic is too sensitive to address in a FAQ, as
well as being difficult to maintain an up-to-date list.


------------------------------

Date: Thu Mar 3 12:38:31 1994
From: [e-mail]
Subject: 8: What are some of the basic design decisions in a firewall?

There are a number of basic design issues that should be
addressed by the lucky person who has been tasked with the
responsibility of designing, specifying, and implementing or
overseeing the installation of a firewall.

The first and most important is reflects the policy of how
your company or organization wants to operate the system: is
the firewall in place to explicitly deny all services except
those critical to the mission of connecting to the net, or
is the firewall in place to provide a metered and audited
method of "queuing" access in a non-threatening manner.
There are degrees of paranoia between these positions; the
final stance of your firewall may be more the result of a
political than an engineering decision.

The second is: what level of monitoring, redundancy, and
control do you want? Having established the acceptable risk
level (e.g.: how paranoid you are) by resolving the first
issue, you can form a checklist of what should be monitored,
permitted, and denied. In other words, you start by figuring
out your overall objectives, and then combine a needs
analysis with a risk assessment, and sort the almost always
conflicting requirements out into a laundry list that
specifies what you plan to implement.

The third issue is financial. We can't address this one here
in anything but vague terms, but it's important to try to
quantify any proposed solutions in terms of how much it will
cost either to buy or to implement. For example, a complete
firewall product may cost between $100,000 at the high end,
and free at the low end. The free option, of doing some
fancy configuring on a Cisco or similar router will cost
nothing but staff time and cups of coffee. Implementing a
high end firewall from scratch might cost several man-
months, which may equate to $30,000 worth of staff salary
and benefits. The systems management overhead is also a
consideration. Building a home-brew is fine, but it's
important to build it so that it doesn't require constant
and expensive fiddling-with. It's important, in other words,
to evaluate firewalls not only in terms of what they cost
now, but continuing costs such as support.

On the technical side, there are a couple of decisions to
make, based on the fact that for all practical purposes what
we are talking about is a static traffic routing service
placed between the network service provider's router and
your internal network. The traffic routing service may be
implemented at an IP level via something like screening
rules in a router, or at an application level via proxy
gateways and services.

The decision to make here is whether to place an exposed
stripped-down machine on the outside network to run proxy
services for telnet, ftp, news, etc., or whether to set up a
screening router as a filter, permitting communication with
one or more internal machines. There are plusses and minuses
to both approaches, with the proxy machine providing a
greater level of audit and potentially security in return
for increased cost in configuration and a decrease in the
level of service that may be provided (since a proxy needs
to be developed for each desired service). The old trade-off
between ease-of-use and security comes back to haunt us with
a vengeance.

------------------------------

Date: Thu Mar 10 16:56:35 1994
From: [e-mail]
Subject: 9: What are proxy servers and how do they work?

A proxy server (sometimes referred to as an application
gateway or forwarder) is an application that mediates
traffic between a protected network and the Internet.
Proxies are often used instead of router-based traffic
controls, to prevent traffic from passing directly between
networks. Many proxies contain extra logging or support for
user authentication. Since proxies must "understand" the
application protocol being used, they can also implement
protocol specific security (e.g., an FTP proxy might be
configurable to permit incoming FTP and block outgoing
FTP).

Proxy servers are application specific. In order to support
a new protocol via a proxy, a proxy must be developed for
it. SOCKS is a generic proxy system that can be compiled
into a client-side application to make it work through a
firewall. Its advantage is that it's easy to use, but it
doesn't support the addition of authentication hooks or
protocol specific logging. For more information on SOCKS,
see ftp.nec.com: /pub/security/socks.cstc   Users are
encouraged to check the file "FILES" for a description
of the directory's contents.


------------------------------

Date: Mon Jun 6 10:07:36 1994
From: [e-mail]
Subject: 10: What are some cheap packet screening tools?

The Texas AMU security tools include software for
implementing screening routers (FTP net.tamu.edu,
pub/security/TAMU).  Karlbridge is a PC-based screening
router kit (FTP nisca.acs.ohio-state.edu, pub/kbridge). A
version of the Digital Equipment Corporation "screend"
kernel screening software is available for BSD/386,
NetBSD, and BSDI. Many commercial routers support screening
of various forms.

------------------------------

Date: Mon Jun 6 10:05:51 1994
From: [e-mail]
Subject: 11: What are some reasonable filtering rules for my Cisco?

The following example shows one possible configuration for
using the Cisco as a filtering router.  It is a sample that
shows the implementation of a specific policy. Your policy
will undoubtedly vary.

In this example, a company has Class B network address of 128.88.0.0
and is using 8 bits for subnets.   The Internet connection is on the
"red" subnet 128.88.254.0.  All other subnets are considered trusted
or "blue" subnets.

     +---------------+ +---------------+
     | IP provider   | |   Gateway     |
     | 128.88.254.1  | | 128.88.254.2  |
     +------+--------+ +------+--------+
            |                            "Red" net
  ----------+-----------------+----------------------------------
                              |
                       +------+--------+
                       |   Cisco       |
                       | 128.88.254.3  |
                       |...............|
                       | 128.88.1.1    |
                       +---------------+
                              |
  ----------------------------+----------------------------------
            |                            "Blue" net
     +------+--------+
     | mail router   |
     | 128.88.1.2    |
     +---------------+


Keeping the following points in mind will help in understanding the
configuration fragments:

  1. Ciscos applying filtering to output packets only.
  2. Rules are tested in order and stop when the first match is found.
  3. There is an implicit deny rule at the end of an access list that
     denies everything.

The example below concentrates on the filtering parts of a configuration.
Line numbers and formatting have been added for readability.

The policy to be implemented is:
     - Anything not explicitly allowed is denied
     - Traffic between the external gateway machine and
       blue net hosts is allowed.
     - permit services orginating from the blue net
     - allow a range of ports for FTP data connections back to the
       blue net.

     1  no ip source-route
     2  !
     3  interface Ethernet 0
     4  ip address 128.88.1.1 255.255.255.0
     5  ip access-group 10
     6  !
     7  interface Ethernet 1
     8  ip address 128.88.254.3 255.255.255.0
     9  ip access-group 11
    10  !
    11  access-list 10 permit ip 128.88.254.2 0.0.0.0
         128.88.0.0 0.0.255.255
    12  access-list 10 deny   tcp 0.0.0.0 255.255.255.255
         128.88.0.0 0.0.255.255 lt 1025
    13  access-list 10 deny   tcp 0.0.0.0 255.255.255.255
         128.88.0.0 0.0.255.255 gt 4999
    14  access-list 10 permit tcp 0.0.0.0 255.255.255.255
         128.88.0.0 0.0.255.255
    15  !
    16  access-list 11 permit ip 128.88.0.0 0.0.255.255
         128.88.254.2 0.0.0.0
    17  access-list 11 deny   tcp 128.88.0.0 0.0.255.255
         0.0.0.0 255.255.255.255 eq 25
    18  access-list 11 permit tcp 128.88.0.0 0.0.255.255
         0.0.0.0 255.255.255.255

Lines   Explanation
=====   ===========
    1   Although this is not a filtering rule, it is good to include here.

    5   Ethernet 0 is on the red net.  Extended access list 10 will
        be applied to output on this interface.  You can also
        think of output from the red net as input on the blue net.

    9   Ethernet 1 is on the blue net.  Extended access list 11 will
        be applied to output on this interface.

   11   Allow all traffic from the gateway machine to the blue net.

12-14   Allow connections originating from the red net that come in
        between ports 1024 and 5000.  This is to allow ftp data
        connections back into the blue net.  5000 was chosen as the
        upper limit as it is where OpenView starts.

        Note: again, we are assuming this is acceptable for the given policy.
              There is no way to tell a Cisco to filter on source port.
              Newer versions of the Cisco firmware will apparently support
              source port filtering.

        Since the rules are tested until the first match we must use this
        rather obtuse syntax.

   16   Allow all blue net packets to the gateway machine.

   17   Deny SMTP (tcp port 25) mail to the red net.

   18   Allow all other TCP traffic to the red net.


Cisco.Com has an archive of examples for building firewalls
using Cisco routers, available for FTP from: ftp.cisco.com
in  /pub/acl-examples.tar.Z

------------------------------

Date: Thu Mar 3 13:52:47 1994
From: [e-mail]
Subject: 12: How do I make DNS work with a firewall?

Some organizations want to hide DNS names from the outside.
Many experts disagree as to whether or not hiding DNS names
is worthwhile, but if site/corporate policy mandates hiding
domain names, this is one approach that is known to work.

This approach is one of many, and is useful for
organizations that wish to hide their host names from the
Internet. The success of this approach lies on the fact that
DNS clients on a machine don't have to talk to a DNS server
on that same machine.  In other words, just because there's
a DNS server on a machine, there's nothing wrong with (and
there are often advantages to) redirecting that machine's
DNS client activity to a DNS server on another machine.

First, you set up a DNS server on the bastion host that the
outside world can talk to. You set this server up so that it
claims to be authoritative for your domains.  In fact, all
this server knows is what you want the outside world to
know; the names and addresses of your gateways, your
wildcard MX records, and so forth.  This is the "public"
server.

Then, you set up a DNS server on an internal machine.  This
server also claims to be authoritiative for your domains;
unlike the public server, this one is telling the truth.
This is your "normal" nameserver, into which you put all
your "normal" DNS stuff.  You also set this server up to
forward queries that it can't resolve to the public server
(using a "forwarders" line in /etc/named.boot on a UNIX
machine, for example).

Finally, you set up all your DNS clients (the
/etc/resolv.conf file on a UNIX box, for instance),
including the ones on the machine with the public server, to
use the internal server.  This is the key.

An internal client asking about an internal host asks the
internal server, and gets an answer; an internal client
asking about an external host asks the internal server,
which asks the public server, which asks the Internet, and
the answer is relayed back.  A client on the public server
works just the same way.  An external client, however,
asking about an internal host gets back the "restricted"
answer from the public server.

This approach assumes that there's a packet filtering
firewall between these two servers that will allow them to
talk DNS to each other, but otherwise restricts DNS between
other hosts.

Another trick that's useful in this scheme is to employ
wildcard PTR records in your IN-ADDR.ARPA domains. These
cause an an address-to-name lookup for any of your non-
public hosts to return something like "unknown.YOUR.DOMAIN"
rather than an error.  This satisfies anonymous FTP sites
like ftp.uu.net that insist on having a name for the
machines they talk to. This may fail when talking to sites
that do a DNS cross-check in which the host name is matched
against its address and vice versa.

Note that hiding names in the DNS doesn't address the
problem of host names "leaking" out in mail headers,
news articles, etc.

------------------------------

Date: Thu Mar 3 21:14:24 1994
From: [e-mail]
Subject: 13: How do I make FTP work through my firewall?

Generally, making FTP work through the firewall is done
either using a proxy server or by permitting incoming
connections to the network at a restricted port range, and
otherwise restricting incoming connections using something
like "established" screening rules. The FTP client is then
modified to bind the data port to a port within that range.
This entails being able to modify the FTP client application
on internal hosts.

    A different approach is to use the FTP "PASV"
option to indicate that the remote FTP server should permit
the client to initiate connections. The  PASV approach
assumes that the FTP server on the remote system supports
that operation. (See RFC1579 for more information)

    Other sites prefer to build client versions of
the FTP program that are linked against a SOCKS library.

------------------------------

Date: Mon Mar 7 13:00:08 1994
From: [e-mail]
Subject: 14: How do I make Telnet work through my firewall?

Telnet is generally supported either by using an application
proxy, or by simply configuring a router to permit outgoing
connections using something like the "established" screening
rules. Application proxies could be in the form of a standalone
proxy running on the bastion host, or in the form of a SOCKS
server and a modified client.

------------------------------

Date: Thu Mar 3 14:16:12 1994
From: [e-mail]
Subject: 15: How do I make Finger and whois work through my firewall?

Permit connections to the finger port from only trusted
machines, which can issue finger requests in the form of:
finger [e-mail]@firewall

This approach only works with the standard UNIX version of
finger. Some finger servers do not permit user@host@host
fingering.

Many sites block inbound finger requests for a variety of
reasons, foremost being past security bugs in the finger
server (the Morris internet worm made these bugs famous)
and the risk of proprietary or sensitive information being
revealed in user's finger information.

------------------------------

Date: Thu Mar 3 12:40:54 1994
From: [e-mail]
Subject: 16: How do I make gopher, archie, and other services work through my firewall?

This is still an area of active research in the firewall
community. Many firewall administrators support these
services only through the character-cell interface provided
by telnet. Unfortunately, many of the sexier network
services make connections to multiple remote systems,
without transmitting any inline information that a proxy
could take advantage of, and often the newer information
retrieval systems transmit data to local hosts and disks
with only minimal security. There are risks that (for
example) WAIS clients may request uuencoded files, which
decode and modify security related files in the user's home
directory. At present, there is a lot of head-scratching
going on between the firewall administrators who are
responsible for guarding the network perimeters, and the
users, who want to take advantage of these very sexy and
admittedly useful tools.

------------------------------

Date: Mon Jun 6 10:12:03 1994
From: [e-mail]
Subject: 17: What are the issues about X-Window through a firewall?

    X Windows is a very useful system, but unfortunately has
some major security flaws. Remote systems that can gain or spoof
access to a workstation's X display can monitor keystrokes that
a user enters, download copies of the contents of their windows,
etc.

    While attempts have been made to overcome them (E.g.,
MIT "Magic Cookie") it is still entirely too easy for an attacker
to interfere with a user's X display.  Most firewalls block all X
traffic. Some permit X traffic through application proxies such as
the DEC CRL X proxy (FTP crl.dec.com).

------------------------------

Date: Thu Mar 24 14:05:27 1994
From: [e-mail]
Subject: 18: Glossary of firewall related terms

Host-based Firewall:
    A firewall where the security is implemented in software running
    on a general-purpose computer of some sort. Security in host-based
    firewalls is generally at the application level, rather than at a
    network level.

Router-based Firewall:
    A firewall where the security is implemented using screening
    routers as the primary means of protecting the network.

Screening Router:
    A router that is used to implement part of the security of a
    firewall by configuring it to selectively permit or deny
    traffic at a network level.

Bastion Host:
    A host system that is a "strong point" in the network's security
    perimeter. Bastion hosts should be configured to be particularly
    resistant to attack. In a host-based firewall, the bastion host
    is the platform on which the firewall software is run.
    Bastion hosts are also referred to as "gateway hosts."

Dual-Homed Gateway:
    A firewall consisting of a bastion host with 2 network interfaces,
    one of which is connected to the protected network, the other of
    which is connected to the Internet. IP traffic forwarding is
    usually disabled, restricting all traffic between the two networks
    to whatever passes through some kind of application proxy.

Application Proxy:
    An application that forwards application traffic through a
    firewall. Proxies tend to be specific to the protocol they
    are designed to forward, and may provide increased access
    control or audit.

Screened Subnet:
    A firewall architecture in which a "sand box" or "demilitarized
    zone" network is set up between the protected network and the
    Internet, with traffic between the protected network and the
    Internet blocked. Conceptually, this is similar to a dual-homed
    gateway, except that an entire network, rather than a single
    host is reachable from the outside.




Contributors:
-------------
[e-mail] - Marcus Ranum, Trusted Information Systems
[e-mail] - Allen Leibowitz, Warner Lambert Inc.
[e-mail] - Brent Chapman, Great Circle Associates
[e-mail] - Brian Boyle, Exxon Research